1. Field of the Invention
The invention relates to personal computers with connections for keyboards and auxiliary device, and more particular to personal computers that operate in a reduced power mode in which the keyboard and auxiliary device can be both disabled and removed from their connections.
2. Description of the Related Art
Personal computers compatible with the International Business Machines Corp. (IBM) PC/AT and its progeny have historically provided both physical and software interfaces for a keyboard and an auxiliary device. These interfaces are now standardized, and any IBM compatible machine must implement such keyboard and auxiliary serial interfaces using standard I/O ports and providing a standard command and data interface for those I/O ports. This software and hardware interface has historically been provided in IBM PC compatible systems by an 8042 peripheral controller by Intel Corp., programmed to direct communication to and from either a keyboard connector or an auxiliary connector. This 8042 command structure standard is well known in the art and is further described in the Compaq DeskPro 386S Personal Computer Technical Reference Guide.
Keyboard and auxiliary devices designed to operate with an IBM compatible personal computer likewise have standardized communications formats for both data and commands. The standard data and command structure for an IBM compatible keyboard can be found in the Compaq DeskPro 386S Personal Computer Technical Reference Guide in Chapter 11. Pointing devices, such as mice and trackballs, are often used as the auxiliary device of choice. A standard for a serial mouse typically used as an auxiliary device is that used by the IBM PS/2 mouse. The specifications can be found in Appendix A.
The standardization of the keyboard and mouse command sets has allowed third party manufacturers to design and market keyboards and mice that can be directly connected to an IBM compatible personal computer and immediately function properly. The standardization of the personal computer hardware and firmware has allowed software developers to communicate with these devices in a standardized way, without the need to patch their programs for different system communications hardware.
These standardized interfaces and standardized devices, however, do include limitations that have become especially apparent during the current proliferation of portable, laptop, notebook, and notepad style computers. The original IBM personal computer was a desktop-based machine, and the software and hardware developers could presume any keyboard or mouse would already be attached to the system at the time the system was turned on. With the new breed of portable computers, however, a keyboard and mouse are preferably detachable to allow for stand alone operation of the computer, and further to allow rearranging of the keyboard and mouse by attaching them to different locations, such as when the portable computer user connects their computer to a desktop expansion base.
Connection and disconnection of these devices, however, results in certain difficulties for the operating system BIOS and application software. When a standard system is first turned on, the power on self-test (POST) and initialization routines send certain commands to the keyboard and auxiliary communication ports and look for specific responses to determine if a keyboard or auxiliary device is attached to the system. If a response is detected, the POST and initialization routines load appropriate device drivers; if no such response is detected, however, the routines omit such drivers. This reduces memory usage in desktop machines that do not have an attached keyboard or auxiliary device.
Standard system software, however, cannot dynamically add device drivers for devices subsequently attached to the system, unless special commands are executed, which require additional user actions. Thus, if a laptop user turns on the machine without such devices attached, standard system software will fail to load the appropriate device drivers. If such devices are subsequently attached, the user will have no way to communicate with or otherwise use those devices, without extra and often obscure procedures.
Further, if the driver software is loaded, subsequently disconnecting the keyboard or auxiliary device often causes the system software to lock up. This is because the software enters an infinite loop, waiting for responses from those devices; responses which will never come.
Power considerations in laptops also make it desirable to totally disable the power to an attached keyboard or auxiliary device. A keyboard or auxiliary device is normally deactivated by pulling its clock or data line low. This method of deactivation, however, is not power efficient, as the 5 volt supply to the keyboard or auxiliary device is then drained through a pull-up resistor. Thus, it is desirable to totally cut the power to an attached keyboard or device when in a power savings mode, as this prevents power consumption by-the pull up resistor.
Cutting off all power to such a device, however, causes the internal controller on that device to lose all of its configuration data stored in its random access memory. When the device is again powered on, it will not contain the configuration state as previously set up by the system or the application software. Further, when the power to the keyboard or auxiliary device is disabled, to the system it will appear the device has been "unplugged", causing the attendant lock-up problems mentioned above.
It would be desirable to force the loading of device drivers during the POST and initialization routines whether or not a keyboard or auxiliary device is attached to its associated connector, to prevent system lock up if a keyboard or auxiliary device is removed during system operation, and to totally disable power to a keyboard or auxiliary device when in a power savings mode without losing the current configuration information for such a keyboard auxiliary device.